Public Key Infrastructure based on the Public Certificates Ledger

ABSTRACT

Systems and methods for managing public key certificates and supporting the users thereof. The certificates are cryptographically encapsulated objects that bind the identities of their owners to public keys and provide digital signature mechanisms for other users to verify the binding and correctness of other attributes of the certificate. Certificates include double links that reflect their validation and position in a public certificates ledger, thereby preventing insertion or removal of certificates in the ledger. Certificate protocols of the system include requesting issuance of certificates, issuing and returning certificates to their requesting users, storing certificates in the certificates ledger, requesting and distributing certificates to transaction partners, verification of certificates by transaction partners, and revoking certificates by their owners. These protocols are performed as direct peer-to-peer transactions between the members of the system.

REFERENCES CITED U.S. Patents

9,344,832 Shell, et al. 9,344,282 Yoo, et al. 9,344,425 Belton, et al.US 20080244685 Andersson, et al. US 20150164192 A1 Gross, A. US20150324787 A1 Schaffner, D.

Other Publications

Ali, M., et al., “Blockstack: Design and Implementation of a GlobalNaming System with Blockchains”, 2016 USENIX Annual Technical Conference(USENIX ATC'16)

Bitcoin (web site) https://en.bitcoin.it/wiki, 2010

BitID (web site) “BitID Open Protocol”, http://bitid.bitcoin.blue/, 2015

Brickell, E., et al., “Direct Anonymous Attestation”, CCS '04, ACM 2004pp. 132-145

Certificate Transparency (web site)https://www.certificate-transparency.org/

Chaum, D., “Security without identification: transactions system to makebig brother obsolete”, CACM, 1985

Dot-bit (web site) http://dot-bit.org/

Fromknecht, C., et al., “CertCoin: A Namecoin based decentralizedAuthentication System”, MIT, Class 6,857 Project, May 14, 2014

Fromknecht, C., et al., “A Decentralized Public Key Infrastructure withIdentity Retention”, MIT, Class 6,857 Project, Nov. 11, 2014

Garman, Ch., et al., “Decentralized Anonymous Credentials”, IACRCryptology ePrint Archive, 2013:622, 2013

Maymonker, P., at al., “Kademlia: A peer-to-peer information systembased on the XOR metric”, http://kademlia.scs.cs.nyu.edu

Melara, M., et al., “CONIKS: Bringing Key Transparency to End Users”,247h USENIX Security Symposium

Namecoin (web site) https://www.namecoin.org/

RFC 5280, Cooper, D. et al, “Internet X.509 Public Key InfrastructureCertificate and Certificate Revocation List (CRL) Profile”, IETF RFC5280

RFC 6962, Laurie, B., et al., “Certificate Transparency”, RFC 6962, June2013

Zyskind, G. “Decentralizing Privacy: Using Blockchain to ProtectPersonal Data”, MIT Media Lab

TECHNICAL FIELD OF THE INVENTION

This invention is related to the security, privacy, and anonymity ofpeer-to-peer transactions, without the participation and/or assistanceof third parties. More specifically, it is focused on certificates andcertification protocols based on a globally available, distributed,append-only, public ledger containing certificates as its objects. Thekey contribution and the core innovation is the concept of a public keyinfrastructure in the form of a community-based public certificatesledger that manages certificates using direct, peer-to-peer protocolswithout participation or assistance of any third-party.

BACKGROUND OF THE INVENTION

Public key cryptography is one of the core cryptographic technologiesfor various aspects of computer security. It is well known that to useit effectively, two problems must be solved: the protection of privatekeys and the distribution/validation of public keys. It is also wellknown that the standard approach to the latter problem is to use digital(X.509) certificates that bind the identities of public key owners totheir public keys. Being digitally signed, certificates enableverification of that binding, i.e., the ownership and correctness of thepublic keys. At the time of this invention, the standard solution forthe distribution and validation of certificates and their public keys isthe concept of public key infrastructure (PKI).

At the time of this invention, the security of users, theirapplications, data and transactions, especially when used over the openInternet, is a major concern. Many solutions exist, all providingstandard security services: entity identification, entityauthentication, data confidentiality, data integrity, access control,authorization, and non-repudiation. X.509 certificates and PKI is thecore enabling technology and the supporting infrastructure for thesesecurity services.

But, at the time of this invention, two new categories of services aregaining importance and global attention: user privacy and anonymity.Privacy is defined as a property of an overall system in whichidentities, application data, and transactions are known only toauthorized transaction partners and service providers and not tounauthorized and illegal users, such as hackers. Anonymity is defined asa property of the system where even authorized users and transactionpartners cannot learn about the identities of their transactionpartners.

Standard X.509 certificates cannot be used if privacy and anonymityservices are required. The reasons are that, first, they contain fulland explicit name and other identifying attributes of the certificateowner, the so-called Distinguished Name (DN) and second, they alsocontain the full identity of their issuer. Therefore, both identitiesare recognized by all transaction parties, what violates privacy andanonymity of users.

Another important trend at the time of this invention is theintroduction of so-called peer-to-peer transactions. Those aretransactions that are executed directly between two parties and withoutsupport or participation of any third party. These transactions are moreefficient than transactions performed with third-party assistance. Notonly that they are performed directly between transaction parties, butthey also do not use complex and cumbersome protocols of third-partyproviders. In addition to efficiency, such transactions also provideuser privacy, as there are no parties involved in a transaction otherthan participants themselves. With a suitable selection of identifyingattributes for the parties involved, such transactions can also provideuser anonymity.

Besides the inadequacy of X.509 certificates for applications andtransactions where user privacy and anonymity is required, anotherproblem is that when providing security services, most, if not all ofthose services, are provided by or require the assistance of (trusted)third parties. Such arrangement has no anonymity of users, as thirdparties learn everything about the users participating in thetransactions, sometimes even their sensitive personal data, such ascryptographic keys, bankcard numbers, etc. It is clear that PKI cannotbe used for peer-to-peer transactions, as it requires the use ofCertification Authorities (CAs) as trusted third parties for validationof certificates.

Finally, another important concept related to X.509 certificates and PKIis trust. With PKI roles and protocols, trust must be placed in all CAs.Not only trust that they will perform their functions correctly and in atimely manner, but also that they will not malfunction or cheat, due toillegal modifications or destruction of their software and data. Trustin third parties is the requirement for all standard security servicesand goes directly against the concept of peer-to-peer applications andtransactions. With such transactions, not only that there are no otherparties participating in transactions, but there is no need to trust anycomponent or function of the system. All aspects of each transaction—theidentities of parties in the transaction, the correctness of transactiondata, the validity of a transaction, the date/time of the transaction,and the authorization to participate in, and to perform, thetransaction—must be verified only by the participating partiesthemselves. Obviously, this approach is not possible with PKI and X.509certificates, as all aspects of transaction verification depend upon theverification of X.509 certificates, which is done using the assistanceof trusted third parties.

In conclusion, for peer-to-peer transactions that require security,privacy, and anonymity, the standard components of X.509 certificatesand PKI cannot be used. Because certificates are the backbone of allsecurity services, it is obvious that management and use of certificatesrequire new solutions and new infrastructure without assistance of thirdparties and their protocols. This invention describes such new type ofcertificates, new type of peer-to-peer certificate protocols, and newinfrastructure for management and use of certificates based on globallyavailable, distributed, append-only public ledger without assistance ofany third party.

The certificates infrastructure described in this invention is acomponent of a larger and more general system that supports peer-to-peerexchange of secure, private, and anonymous data and transactions in anopen Internet environment using a public ledger. In principle, a publicledger is a public archive of all transactions that have been performedin the system, and its main purpose is to provide data, mechanisms andprotocols to verify these transactions without assistance of thirdparties. The transactions individually or sometimes grouped in blocksare cryptographically encapsulated and mutually linked in a functional,cryptographic or time sequence. This concept of the public ledger isknown as a blockchain. Thus, conceptually broader system supportssecure, private, and anonymous peer-to-peer transactions based on aconcept of public ledger (blockchain) used to verify transactions. Thissystem is called “Blockchain Information eXchange” (BIX) system.

OVERVIEW OF THE REFERENCES CITED

The ideas described in this invention are innovative. This means that atthe time of this invention, searching publications for the keywords“certificate,” “ledger,” and “blockchain” did not produce any results,implying that equivalent ideas have not yet been published. Forinstance, there exist some ideas called “Bitcoin identities,” but theyare merely the use of user-friendly forms of Bitcoin addresses withoutany additional security services or features. Most current suggestionsfor the security of applications, users, and transactions are based onuse of standard Bitcoin blockchain and they focus on protecting thelocal data used by Bitcoin wallets. Search queries do not retrieve anyscheme or protocol for the secure, reliable, and verifiable distributionof public addresses, keys, and identities, even for the Bitcoin system.The search does not reveal any ideas or concepts of the blockchain asthe public certificates ledger to support the security, privacy, andanonymity of applications or transactions, other than payments usingcryptographic currencies and proof-of-existence for documents.

Therefore, certain concepts from the potential prior art reviewed inthis section are used only as analogies to the solutions described inthis invention and have only vague resemblance to the ideas andsolutions presented in this invention.

An Analogy with X509 Certificates and PKI

One of the purposes of the BIX certificates designed in this inventionis to distribute users' anonymous identities and public keys in order toenable the verification of their correctness, binding, and ownership.This is also one of the purposes of X.509 certificates. Therefore, itmay be assumed that BIX certificates are analogous to X.509certificates. However, the core differences are that (a) usercredentials contained in BIX certificates are anonymous, (b) BIXcertificates are not issued by any trusted third party, (c) BIXcertificates are linked in a public ledger, and (d) BIX certificates arevalidated directly by their users, not third parties on behalf of users.

The standard X.509 certificate profile includes the field version thatis used to designate the version of the certificates. This inventionalso uses the field version in BIX certificates, but it is used todesignate the type rather than the version of the certificate, asexplained in the Detailed Description of the Invention section. Thisfield is equivalent to the attribute keyUsage in X.509 certificates. Thecurrent value of the field version is one (1), denoting a certificatethat can be used for security services, i.e., the anonymousidentification, authentication, and exchange of secret session keys.

The serialNumber field in a standard X.509 certificate is used as thereference to the specific X.509 certificate itself, to identify it fromothers issued by the same CA. It is also used to locate the certificatein the Certificate Revocation Lists (CRLs). BIX certificates are issuedby members of the BIX community and “chained” in the certificatesledger, so a serial number as a reference to a specific issuer is notneeded. However, for easier referencing in the certificates ledger andfor some other purposes, which are explained in the Detailed Descriptionof the Invention section, BIX certificates contain the fieldsequenceNumber.

X.509 certificates have the component Subject. This is the segment withidentifying attributes organized in the form of a Distinguished Name(DN). BIX certificates also have the component subject, but instead of aDN for the explicit identification of a certificate's owner, thiscomponent contains a Personal Identification Number (called a BIXIdentifier) as one of its attributes. This number is randomly assigned,so it represents a pseudonym, and, therefore, such identities of usersprovide their privacy.

X.509 certificates have a validity component comprised of date/timeattributes; one is an issuing date/time and the other is an expirationdate/time. BIX certificates do not expire, so they do not needexpiration date/time.

X.509 certificates have an Issuer segment, which contains the DN of theCA that issued the certificate. In the BIX Certificates Infrastructure(BCI), the issuer is one of the other members of the BIX community. Thestructure of the segment Issuer in BIX certificates is equivalent to thestructure of the segment Subject.

Finally, X.509 certificates have extensions. The purpose of theseextensions is to enhance and, more precisely, to designate the types andpurposes of certificates (i.e., authentication certificates, signaturecertificates, certificate signing certificates, and key exchangecertificates), to identify the supporting components of the PKI (such asthe repositories of revoked certificates and the directories wherecertificates are stored), and to indicate the policy under whichcertificates have been issued. BIX certificates also have extensions.However, specific extensions are not specified because they are used todesignate different aspects of their management and use. So, in BCI,extensions represent “placeholders” for such extended and additionalaspects, which will be more refined in subsequent versions of thesystem.

The main drawbacks of the current concept of the PKIs are that theyrepresent very complex infrastructures, they critically depend upontrust in third parties, and they use complicated procedures todistribute and validate certificates. Another major inconvenience istheir scaling and federation, which may be solved either by issuing allcertificates under one Root Certification Authority or by establishingfederated PKIs. Both approaches are complicated and neither has beenbroadly deployed in practice, which clearly indicates that thesecomplexities are obstacles for the establishment and use of large-scalePKIs. A public certificates ledger has one general advantage over suchlarge and complex infrastructures, built with use and dependent on thirdparties: it does not depend upon and does not use any third parties.This makes it very convenient for many purposes and applications, one ofwhich is the BIX Certificates Infrastructure described in thisinvention.

An Analogy to the Bitcoin System and Its Blockchain

Bitcoin is an anonymous payment system that uses the concept of a publicledger—called a blockchain—to perform and verify payment transactions.Its blockchain has a specific structure and protocols for its creation,distribution, and use and is primarily suitable for paymenttransactions. Some innovative ideas have been to use the same conceptand the existing operational Bitcoin infrastructure to perform othertypes of community-based and anonymous transactions. Some examples areshared file storage, a secure file-sharing system, and a documentmanagement system with digital notary services or proof-of-existence fordocuments.

Although Bitcoin is appropriate for anonymous payments and isoperational at the time of this invention, the system has manyconceptual and operational problems. Some of them are small block size,slow throughput of transactions, vulnerabilities of privatecryptographic keys, cheating by collaboration of miners, etc. Inaddition to all these problems and weaknesses, in order to provide thefull scope of security and anonymity services for other types ofapplications, the system also needs certain conceptual extensions. Notall applications need packaging of transactions in blocks or chaining oftransactions.

BIX certificates support both public key and secret key cryptographicprotocols and services, which is an important distinction compared toBitcoin addresses. Bitcoin transactions are based on addresses that, inessence, represent the recipient's public key; thus, they can be usedonly by a single recipient. BIX certificates, on the other hand, supporttransactions with multiple targets/recipients and also grouptransactions with multiple senders.

In the Bitcoin protocol, the address (or the Bitcoin account) of theuser who will receive payment must be available to the partner who makesthe payment. In addition, all of the partner's previous transactionsmust be available to the person receiving the payment to verify thecorrectness and validity of the payment transaction. However, there isno formal protocol to distribute and verify Bitcoin accounts (addresses)by partners. At the time of this invention, they are mainly distributedout-of-band or in the graphics form, over-the-counter or over-the-Web.In other words, this approach is not satisfactory for businesstransactions that need verified, correct, and legitimate personal andcorporate parameters. With the current concept, the distribution ofBitcoin addresses over the network is vulnerable to man-in-the-middleattacks.

Bitcoin payments are verified by checking that the sender (a) has asufficient balance in his/her account to make the payment and (b) he/shedoes not make double payments. Both verifications are performed bytracing the sequence of all transactions in the blockchain starting fromthe trusted “coinbase” transaction up to the latest transaction receivedby the partner who is making payment. But, for many applications, usingpeer-to-peer transactions that require the verification of personalcredentials and/or transactions, this concept is not appropriate. Forinstance, in an electronic voting application, there is no startingtrusted “coinbase” transaction. Furthermore, “double spending” ispossible, as voting may be simultaneous at the city, regional, and statelevels and the identity of the voter, the correctness of the vote, andthe controlled use of voting rights must all be verified and validated,but with full anonymity.

Peer-to-Peer Applications with Anonymity

After the introduction of the concept of the blockchain by the Bitcoinsystem, many ideas emerged for innovative applications of the blockchainBut, for most of them, the current Bitcoin blockchain is not appropriateat all. First, there are serious problems with the protection,integrity, and availability of Bitcoin credentials. The ownership andcorrectness of public addresses cannot be verified and the protection ofprivate credentials is inadequate. Second, the current concept of theBitcoin blockchain contains only financial and other similartransactions that require linear ordering and linear dependencies oftransaction data. This structure and transaction relationships areinadequate for many applications that need blockchain, but for whichtransactions cannot be organized in a linear structure. Furthermore,while anonymity may be an advantage for certain types of transactions,it presents problems for others. The examples of such transactions arevoting, digital notarization, trading of commodities, etc.

Conclusions

Based on the discussion in this section, it is obvious that the currentconcepts of X.509 certificates, PKI, and Bitcoin payment transactionsand the Bitcoin blockchain for their verification are inadequate for awide spectrum of new and innovative applications, transactions, andservices that need the security, privacy, and anonymity of users, theirtransactions, and their data.

Current problems, trends, innovative applications, and disruptive ideasmotivated the innovation described in this invention. Based on the twoaforementioned examples, Bitcoin payments and electronic voting, the keyconclusion is that personal credentials, such as identities andcryptographic credentials, must be managed separately from applicationsand transactions. Personal credentials are needed to verifyparticipants' membership, authorization, and status in the BIX system.Once that is accomplished, valid and regular BIX members may usedifferent applications and perform different types of transactions, eachof which requires their own application-specific data and credentials.

SUMMARY OF THE INVENTION

The Background of the Invention section mentions several problems withcurrent X.509 certificates and PKI for applications that supportsecurity, privacy, and anonymity and the transactions performed asdirect peer-to-peer transactions without the participation and/orsupport of third parties. This invention solves these problems byintroducing several new concepts and solutions.

First, a new type of cryptographically encapsulated object, called a BIXcertificate, is created. Its purpose is equivalent to X.509certificates, i.e., to support verification of binding between useridentities and their public cryptographic keys and verification of thatbinding and in that way support security services for users andtransactions, but enhanced with privacy and anonymity. BIX certificatesenable applications and transactions whose main purpose is to exchangesensitive personal and business information and data to provide fullsecurity, privacy, and anonymity of their users and data.

Second, the concept of the new certificates infrastructure, called theBIX Certificates Ledger (BCL), is created. As the general concept, aledger is a collection of public user attributes and transactions thatare linked in a time, cryptographic, and/or functionality sequence.Certificates included in a public certificates ledger are available toall users who use some application that requires verification of userattributes and transactions data, but with user anonymity. Contrary tothe concept of the Bitcoin, the BCL and all of its protocols are trulypeer-to-peer, i.e., community-based, without requiring third-partyassistance.

Third, the new concept of certificates protocols is created. Theprotocols are performed in the BIX Certificates Infrastructure andsupport the following functions for users and their certificates:requesting own certificates, issuing and returning certificates to theirrequesting users, storing certificates in the public certificatesledger, requesting and distributing certificates to the transactionpartners of certificate owners, enabling verification of certificates bytransaction partners, and revoking certificates by their owners.

The fourth innovative idea and solution to the three problems is theconcept of community transactions. A community is a group of anonymoususers who have agreed to participate in some application(s) or tosupport the security, privacy, and anonymity services provided by theBCL. An example is a community for sharing files or proving proof forthe existence of documents. Users join the community only to participatein community-based transactions, such as, for example, for making adonation to charity. It is important to emphasize that users do not haveto trust the members of the community, as verification of theiridentities and certificates is one of the main purposes of the BCIitself. Even if malicious users are members of a community, they cannotdamage other members in the BCI, or the BCI's certificates andprotocols.

It should be emphasized that the concept of the BCI specified in thisinvention is both unpermissioned and also permissioned infrastructure.If the infrastructure is unpermissioned this means that it does not havesponsoring entities that approve users who want to join theinfrastructure. In other words, any user can join without beingapproved, sponsored, or supported by any other party, except users whoare already the members of the BIX community. However, someapplications, such as banking, trading stock, paying taxes, or voting,require entities that approve users to join the infrastructure andperform transactions with security, privacy, and anonymity. BCI withsuch type of entities is called permissioned. Participants,certificates, and protocols in that type of certificates infrastructureare the same as in the community-based, unpermissioned infrastructuredescribed in this invention. The details of a permissionedinfrastructure are different only with respect to registration of usersin the BIX system, what is the protocol described in another invention.

The solutions described in this invention resolve the conflict between,on the one hand, the requirement for explicit sharing of identities andcredentials for security services and, on the other hand, the preventionof that sharing to ensure privacy and anonymity. The cryptographicobjects and protocols described in this invention can be used with allcommunity-based applications that require privacy and anonymity ofvalidated users. Therefore, based on the new concept of the publiccertificates ledger, BIX certificates, the protocols for theirmanagement and use, and the infrastructure for their distribution andverification represent technologies and infrastructure supporting a newcategory of applications that provide security, privacy, and anonymity.In that sense, the system described in this invention enables secure,private, and anonymous transactions equivalent to what X.509certificates and PKI enable for users, applications, and transactionsthat require only security services.

In summary, the innovative ideas and solutions described in thisinvention solve three important problems for users, applications, andpeer-to-peer transactions that require security, privacy, and anonymity:(a) the provision of peer-to-peer transactions that requireidentification, authentication, and authorization of users while alsoensuring their privacy and anonymity, (b) the provision of security,privacy, and anonymity services by a community of users withoutthird-party assistance, and (c) the provision of secure, private, andanonymous peer-to-peer applications and transactions without centralizedapplication providers.

DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the complete structure of the BIX certificate in the ASN.1encoded form

FIG. 2 shows the attributes of the BIX Root Certificate after itscreation

FIG. 3 shows Root Certificate and the certificate of the first BIXmember before his/her certificate is issued by the BIX CertificatePolicy Authority. The certificate is at the same time CertificationRequest message

FIG. 4 shows Root Certificate and the certificate of the first BIXmember after the Certificate Request by the BIX member has beenprocessed.

FIG. 5 shows Root Certificate and the certificate of the first BIXmember after validation by the BIX member being certified

FIG. 6 shows an instance of the BIX Certificates Ledger

DETAILED DESCRIPTION OF THE INVENTION

The Structure and Attributes of BIX Certificates

BIX certificates are cryptographically encapsulated objects that providebinding between identities of their owners and their public keys,provide cryptographic mechanism (digital signature) to verify thatbinding and correctness of certificate attribute values and in that wayenable distribution of identities and cryptographic keys to transactionpartners and verification of the binding and correctness of attributevalues by those partners. These features with BIX certificates areachieved with the full anonymity of all BIX system members.

The structure and attributes of BIX certificates and protocols for theircreation, distribution, and verification support the three main purposesof these certificates: (1) reliably distributing and using the correctand legal identities and correct cryptographic keys of BIX systemmembers, (2) verification of user identities and cryptographic keys, and(3) binding of identities to public cryptographic keys used for thesecurity, privacy, and anonymity of various applications andtransactions. These three purposes are met by BIX certificates havingthe following features and properties:

-   -   (1) They provide a method to verify that the attribute        representing the public key contained in the certificate is        correct, that is, the public key is created and owned by the        designated certificate's owner;    -   (2) The recipient of the certificate is able to verify that        there exists a private key that corresponds to the public key        contained in the certificate, that is, the public key is not        false and fabricated;    -   (3) They provide a method to verify that the anonymous        identifier of the owner of the certificate is correct and        globally unique, that is, the owner of the certificate has been        registered in the BIX system;    -   (4) It is possible to verify that the binding of the public key        to the anonymous identifier of the owner of the certificate is        correct;    -   (5) There is a method to verify that the issuing date/time is        correct;    -   (6) The BIX system member, when using the certificate of his/her        transaction partner, can verify the validity of the certificate,        i.e., that the values of all of its attributes are correct.

All of these requirements mean that public keys must be distributedwithout a threat of accidental or intentional modifications, thatillegal insertions of fake certificates must be prevented and detected,that the unauthorized substitution of correct certificates must bedetected, and that certificates' validity and correctness must beverifiable.

In addition to distributing anonymous identities and cryptographic keys,BIX certificates may also be extended with additional attributes inorder to meet the functional requirements or other properties, suitablefor or required by different types of applications beyond payments.

FIG. 1 shows the attributes and the structure of BIX certificates. Itsattributes are as follows:

Header: The Header 101 is a segment with three fields.

-   -   sequenceNumber: This field contains the sequence number of the        certificate and reflects its relative position within the BIX        Certificates Ledger with respect to the certificates of other        BIX members.    -   version: This field contains the value that designates the type        of the BIX certificate.    -   issuingDateTime: This field indicates the date and time of        issuance of the certificate. It represents the start of the        validity period for the current certificate.

Subject: 102 This is a segment with four attributes.

-   -   subjectBIXID: This is the unique global identifier of the user        who owns the certificate.    -   subjectDateTime: This field indicates the date and time of        creation of the public/private key pair.    -   signatureAlg: This field designates the cryptographic algorithm        with which the public key can be used.    -   subjectPublicKey: This is the cryptographic public key that        belongs to the owner of the certificate.

SubjectSignature: 103 This field contains the signature over the fourSubject attributes created with the private key that corresponds to thepublic key contained in Subject segment. Therefore, the Subject segmentis self-signed.

Issuer: 104 This is the same group of four attributes as in Subject, butthey belong to the BIX member who issued this certificate.

IssuerSignature: 105 This is a self-signed signature over the fourIssuer attributes created by the issuer.

BackwardCrossSignature: 106 This field contains a double signature, onecreated by the issuer and the other created by the subject, over threeHeader fields concatenated with the hash of the Subject segment and thehash of the Issuer segment. This field guarantees the validity of Headerand the binding between Subject and Issuer.

NextSubject: 107 This is the segment with four attributes equivalent tothe Subject segment, but these attributes belong to the BIX member whowas certified by this BIX member, i.e., it contains the Subjectattributes of the next member in the BCL

NextSubjectSignature: 108 This is the field equivalent to theSubjectSignature, except it is created by the issuer over NextSubjectattributes.

ForwardCrossSignature: 109 This field contains a double signature, onecreated by the issuer and the other created by the NextSubject BIXmember over three Header fields concatenated with the hash of the Issuersegment and the hash of the NextSubject segment. This field guaranteesbinding between current BIX member, as the issuer of the nextcertificate, and the next BIX member to whom the certificate is issued

Extensions: 110 This field contains extnID and the value and criticalityflags for the additional attributes that may be needed for specificpurposes of the BIX certificate.

The field version in BIX certificates is used to designate the type ofcertificate. It is equivalent to the keyUsage attribute in X.509certificates. If the value of the field version is one (1), it indicatesa certificate that can be used for security services for anonymousidentification, authentication, and exchange of secret session keys.Other values may be used in the future to denote other types ofcertificates, such as CRL-signing certificates and/or attributecertificates.

The field CertificateSerialNumber in the standard X.509 certificaterefers to the specific X.509 certificate among those issued by aspecific CA. It is also used to locate the certificate in CRLs. BIXcertificates are issued by members of the BIX community and chained inthe BCL, so serial numbers are not needed as a reference to the specificissuer. However, for easier referencing and for locating the certificatewithin the BCL, BIX certificates contain the field sequenceNumber. Thisfield's content and its use are explained the section BCI CertificateProtocols, A.

BIX certificates have a Subject segment, as do X.509 certificates. Butinstead of a DN for explicit identification of the certificate's owner,this component contains as one of its attributes a personalidentification number (called a BIXIdentifier). Personal IDs are randomnumbers that are publicly available, globally unique, and anonymous inthe BIX system. They are used as convenient references to individuals,equivalent to mobile numbers. They are unique and permanently assignedto BIX members. BIX certificates may be renewed and several of them maybelong to the same member at the same time. Personal ID in the BIXsystem is unique, equivalent to a social security number issued in theUnited States, which is issued to a person once in his/her lifetime andis permanent and unique. BIX certificates in the Subject segment containa public key and the associated algorithm identifier in the fieldssubjectPublicKey and signatureAlg. Four fields comprising the Subjectsegment: subjectBIXID, issuingDateTime, signaureAlg, andsubjectPublicKey are signed. Because BIX certificates are created bytheir owners, the SubjectSignature field is created using a private keythat corresponds to the public key in the Subject segment. This meansthat the Subject segment is self-signed.

BIX certificates do not expire, so they do not need an expirationdate/time. The Subject segment of the BIX certificate contains asubjectDateTime field designating the time of its creation, i.e., thegeneration of the cryptographic keys pair. Locating certificates in theBCL and verifying their time validity is based on the specialcertification protocols. BIX certificates are chained in the BCL usingpersonal BIX Identifiers and cross-signatures and organized in a timesequence using the field issuerDateTime from the Issuer segment.

In the BCI, the issuer of each certificate is one of the other membersof the BIX community. The structure of the Issuer segment in BIXcertificates is equivalent to the structure of the segment Subject. TheIssuerSignature field is equivalent to the SubjectSignature field inthat it contains signature over the Issuer segment, created by thecertificate's issuer.

Other fields and segments of the BIX certificate, shown in FIG. 1, willbe explained in subsequent sections.

The BIX Certificates Infrastructure (BCI) and Protocols

The BCI is (a) the collection of all BIX certificates issued to BIXmembers (users and applications) organized in the form of adouble-linked list called certificates ledger, (b) components thatmanage these certificates, and (c) the corresponding protocols for theircreation, distribution, and verification. Because no third parties areinvolved, the entities managing certificates are the BIX membersthemselves. This means that members have two roles: as users of theinfrastructure and also as certification and validation authorities. Ifthe infrastructure is unpermissioned, any person may join the community,obtain, and then use certificates for secure, private and anonymoustransactions. If the infrastructure is permissioned, then there are themembers of the community with the special role to validate and approveregistration of new users in the infrastructure. So, the differencesbetween permissioned and unpermissioned certificate infrastructures arenot reflected through certification protocols, but through registrationprocedures, that are specified in another invention.

The main component of the BCI is the BCL, which is a linear,double-linked list of certificates without branches. This means thatcertificates are linked to one another in a linear sequence. In fact,BCL represents a certificates chain containing certificates of allmembers that are registered in the system. Each certificate points tothe previous certificate (a “backward” link), that belongs to the BIXmember who issued the certificate, and also points to the nextcertificate (“forward” link) that was issued by this BIX member. Thebackward link is represented by the Issuer segment of the certificateand the forward link is represented by the NextSubject segment.

BCI certificate protocols are performed as direct peer-to-peertransactions between members of the BIX system. The purpose of theseprotocols is to manage BIX certificates. Individual protocols arepeer-to-peer transactions, which include requesting, issuing,distributing, verifying, and renewing BIX certificates. Each userexecutes these protocols using the BCI Agent—which is a PC, server,smart card, smart chip or smart phone application. The application mustbe preconfigured only with the URLs of several of the broadcastdistribution system servers, so it can communicate with the componentsof the BCI to send and receive certificate protocol messages.

The subsystem of the BIX system called BIX Identities System supportsregistration of new users and the distribution of Coordinated UniversalTime (UTC). Before executing the BCI certification protocol, each personmust first register himself/herself in the BIX system. This is performedby registering in the BIX Identities System. Data provided by the userin this step are dependent on the type of the BIX Identities System(permissioned or unpermissioned) and the BIX Synchronization System usedin the particular instance of that system. The most important in thisstep is that the BIX Identities System issues a unique identificationnumber used as a BIX Identifier for the new BIX member.

It must be emphasized that one of the distinguishing features of theBCI, and advantages when compared with the standard X.509 PKIs, is thatall protocol messages have only one object—the BIX certificate itself.Different messages are distinguished by the different content of thecertificate. This simplifies the parsing and processing of protocolmessages, as each step only handles the values of BIX certificateattributes.

Initiation of the BCI—Root Certificate

An instance of the BCI is established by creating its Root Certificate.The BCL starts with the Root Certificate, which is shown in FIG. 2.(Note: The convention for showing certificates in the drawings is thatif a field is populated, it is shown in bold text; otherwise, it isshown in normal text). The Root Certificate is self-signed, i.e., theSubject segment 201 and the Issuer segment 202 are the same. This meansthat the BCI-initiating entity is the owner and also the issuer of theRoot Certificate. This entity is called BIX Certificate PolicyAuthority. To initiate one specific instance of the BCL, the RootCertificate must be issued by an entity that will initiate the specificBCL (equivalent to the genesis transaction in the Bitcoin system).Because when a Root Certificate is initially created, that entity hasstill not issued certificates to any other member in the BIX system, soits fields BackwardCrossSignature 203, NextSubject 204, andForwardCrossSignature 205 are not populated.

After the Root Certificate is generated and inserted into the BCL, thefirst BIX member may be registered and his/her certificate is issued bythe BCI's initiating entity. The details of all BCI certificationprotocols are described in the next section, so at this point it issufficient to mention that when the new certificate is issued by one BIXmember to another:

-   -   the NextSubject segment of the new certificate is left        unpopulated, and    -   the NextSubject segment of the issuing BIX member's certificate        is populated with the Subject segment of the new certificate        (the forward link).        This means that the last BIX member who joined the system is        added to the “tail” of the BCL and he/she will be the issuer of        the next certificate.

The BCL can be traversed both backwards (to reach the Root Certificate)and also forwards to find the tail/the end of the BCL, i.e., to find theuser who is the issuer for the next certificate.

The BCI requires as its operational prerequisite a broadcast messagingsystem with instantaneous delivery of messages. This system, which werefer to as the BIX Synchronization System in this invention, performsthree synchronization functions: (a) global synchronization of randomnumbers used as personal identification numbers for their globaluniqueness within the entire BCI, (b) synchronization of the globalCoordinated Universal Time (UTC), and (c) synchronization of newlyissued certificates providing globally synchronized unique state of theentire BCI. This component of the BIX system is not a third party, as itonly passively distributes BIX certificates and (for address purposes)verifies that the BIX identifier of the new BIX member is unique. Analternative, peer-to-peer message distribution system may also be used.

BCI Certificates Protocols

A. The Certification Request/Response Protocol

The Certification Request/Response protocol is executed by a person whowants to join the BIX system. The purpose of this protocol is to issue aBIX certificate to the new BIX member. This certificate must be issuedby the BIX member who joined the BIX system last, because his/hercertificate is at the tail of the BCL. Before initiating theCertification Request protocol, the new user should have been registeredin the BIX Identity System and in that process should have obtainedhis/her BIX Identifier and an accurate Coordinated Universal Time (UTC).For this purpose, the components of the BIX Identity System have thefunctionality to maintain the Register of issued identifiers, so thatduplicate identifiers are not issued. The BIX Identity System is alsobased on the use of the public ledger, and it is the subject of anotherinvention.

As mentioned in the previous section, the BCL is initiated by the BCICertificate Policy Authority by an action of generating the RootCertificate and publishing in in the BCL. As already described, itsIssuer segment is the same as its Subject segment, i.e., the certificateis self-issued. When the Root Certificate is generated, the BCI is readyto issue the certificate to the next BIX member.

FIG. 3 shows the initial step of the Certification Request/Responseprotocol, performed by the person who wants to join the BIX system. Theprotocol is initiated by the new BIX member who creates a certificationrequest message and sends it to the BIX system. The message is aninstance of the BIX certificate with the Header field 301 partiallypopulated, the Subject segment 302 completely populated, and theattribute SubjectSignature 103 created as follows:

-   -   version is set to one (1)—this denotes the Security Services        Certificate in the BIX Certificates Infrastructure;    -   subjectBIXID is set to the value of the BIX Identifier returned        by the BIX Identity System;    -   subjectDateTime is set to the date/time returned by the BIX        Identity system;    -   signatureAlg is set to the objectID of the cryptographic        algorithm used with asymmetric keys;    -   subjectPublicKey is the public key generated by the user using        local BCI Agent;    -   SubjectSignature is the signature over the complete Subject        segment using the private key that corresponds to the        subjectPublicKey.

Because the new person is completely detached from the BIX system,he/she does not know which BIX member has joined last the BIX system,i.e., who should be the issuer of the new certificate. Therefore, thenew user broadcasts the certificate as a certificate request message toall current members in the BIX system. All members whose certificateshave the Next subject 107 segment populated will disregard the request.Only one member will accept and process the request, the member whosecertificate does not have the segment NextSubject populated. In FIG. 3.,user 1 is the new user and BIX Security Policy Authority is the issuerof the certificate. In all other cases two users are involved in thisprocess, one of them is the issuer of the new certificate having his/hercertificate with both Subject and Issuer segments populated.

That BIX member will be the issuer of the new certificate, which isissued by the following procedure:

-   -   sequenceNumber is populated with the value one higher than the        value of the sequence number in the issuer's certificate;    -   issuingDateTime is set by the issuer to the current accurate        date and time—Coordinated Universal

Time (UTC). The Issuer segment and IssuerSignature are the Subjectsegment and subjectSignature from the issuer's certificate; therefore,they are copied into the new certificate.

After populating the Header 401 and Issuer 402 segments, the issuerrecovers the hashes from the SubjectSignature and IssuerSignaturefields, concatenates them with the hash of attributes from the nowcompleted Header segment and signs that combination of hashes using theissuer's private key, creating an intermediate (single-signed) versionof the field BackwardCrossSignature 403. In that way, the issuer bindsthe Subject segment from his/her own certificate with the Subjectsegment from the certificate of the new BIX member and creates asequential relationship between the issuing BIX member and the new BIXmember. This relationship is also enforced by the values of the fieldsequenceNumber of the two certificates, as the new certificate iscreated with the value of the sequenceNumber that is one larger than thevalue of the sequenceNumber of the issuer's certificate.

At the same time, the issuer updates the NextSubject 404 segment ofhis/her own certificate with the Subject segment of the new certificate.Then, he/she creates an intermediate (single-signed) version of thefield ForwardCrossSignature 405 over the concatenated hash of the Headerwith the two hashes that were extracted from the SubjectSignature fieldand the NextSubjectSignature field of his/her certificate. This is shownin FIG. 4 as the relationships between certificates of the BCI RootAuthority and User 1.

After completing the certificate of the new BIX member and extendinghis/her own certificate, as described, the issuer returns threecertificates to the new user by submitting them to the BIXSynchronization System as a Certification Response message that includesthe Root Certificate, its own certificate, and the certificate of thenew BIX member. In the case of the very first user, only twocertificates are returned: the Root Certificate and new BIX member'scertificate. The two cross—linked certificates are shown in FIG. 5. Theattribute ForwardCrossSignature 109 of the issuer's certificate and theattribute BackwardCrossSignature 106 of the new member's certificatehave the same values that are signed. The value of theForwardCrossSignature 501 attribute of the issuer's certificate iscreated using private key of the issuer, while the value of theBackwardCrossSignature 502 attribute of the new member's certificate iscreated using private key of the new member.

B. The Certificate Verification Protocol

After receiving three certificates, the new BIX member performsverification of the new certificate using two procedures:

(1) Completion ofthe issuer's certificate: He/she counter-signs theForwardCrossSignature 501 attribute of the issuer's certificate andreturns that certificate to the issuer. In that way, the relationshipbetween the issuer and the new member as his/her successor in the BCL isestablished. The purpose of this is to prevent the issuer fromeventually being able to cheat by removing the NextSubject segment fromhis/her certificates and issuing the certificate to another user. Thatwould “detach” the complete section of the BCL located beyond thecheating member. With the cross-signed field ForwardCrossSignature inthe issuer's certificate, the new BIX member is tightly linked into theBCL, as he/she has the proof of who is the issuer of his/her newcertificate.

(2) Verification of the new certificate: The new BIX membercounter-signs the field BackwardCrossSignature 502 in his/her owncertificate and, in that way, links it to the certificate of the issuer.After that, the member verifies the issuer's certificate by traversingthe complete BCL either forward, starting with the Root Certificate andfollowing the NextSubject references, or backward, starting from his/hercertificate and following the Issuer references.

During the verification process, the new BIX member accumulates allcertificates from the BCL, which is equivalent to downloading theblockchain in the Bitcoin payment system. Each certificate is verifiedand stored in the local storage of the BCI Agent containing verified,and therefore trusted, certificates of other BIX members for future use.It may be emphasized that this certificate verification procedure doesnot use and does not depend upon any third party. The user does not needto trust any other component in the system and the main purpose of theBCL is utilized by a pure peer-to-peer protocol.

C. The Certificate Request/Response Protocol

When a BIX member wants to establish a secure session or to perform somesecure transaction with another BIX member, the two members must firstexchange their BIX certificates. To do so, after establishing acommunication connection and, eventually, an application context, eachuser sends his/her own BIX certificate to the other user. Because oneuser usually initiates the transaction, these two messages may beconsidered the Certificate Request and the Certificate Reply,respectively.

Alternatively, two users may also request and fetch certificates fromthe BCL.Since each certificate has its unique identification(sequenceNumber), BCL is organized as index-sequential database.Therefore, BCI Agent can retrieve the requested certificate by directread.

After receiving the partner's BIX certificate, the receiver must firstverify the certificate before using its attributes. Verificationcomprises two steps: verification of the fields included in thepartner's certificate and verification of the membership of the partnerin the BIX system. The first verification is performed by verifying theSubjectSignature 103, IssuerSignature 105, and BackwardCrossSignature106. Both public keys for this verification are already available in thereceived partner's certificate. The membership of the partner in the BIXsystem is checked by verifying that the partner's certificate isincluded in the BCL. This procedure is equivalent to the verification ofthe user's own certificate after its issuance, i.e., by traversing theBCL from the partner's certificate backward to the already verifiedcertificate. For that, the Issuer segment of each certificate beingverified is used as the reference.

Referring to FIG. 6, assume that BIX members with certificate numbers 51602 and 99 604 have just exchanged certificates and they want to verifyeach other's certificates. This procedure starts with the partner'scertificate and may fall under one of three scenarios:

(1) If the partner's certificate is located backward in the BCL from themember's own certificate (the partner was registered before the currentmember), then the partner's certificate is already in the local BIXmember's database of verified certificates. This is the case when BIXmember 99 604 validates the certificate of BIX member 51 602;

(2) If the partner's certificate is located forward in the BCL from theBIX member's own certificate (the partner was registered after thecurrent member) and no other forward partners have been previouslyvalidated, then the procedure will terminate when reaching its owncertificate. This is the case when user 51 602 validates the certificateof user 99 604;

(3) If the partner's certificate is located forward in the BCL and someother forward partners have already been validated, then the procedurewill terminate (a) immediately, if the partner's certificate is beforesome already validated certificate, which is the case when BIX member 51602 validates the certificate of BIX member 99 604, but he/she hasalready validated the certificate of BIX member 100 605, or (b) whenreaching the first already validated certificate of some other partner.This is the case when BIX member 51 602 validates the certificate of BIXmember 99 604, but he/she has already validated the certificate of BIXmember 52 603. During the validation procedure, if the partner'scertificate is located forward and beyond all currently validatedcertificates, the current member adds some additional certificates tohis/her local certificates chain, all of those certificates locatedbetween the last validated certificate and the new partner'scertificate. This is the case in (3b) above, when BIX member 51 602,during validation of the certificate of BIX member 99 604 adds tohis/her certificate chain the certificates of all members 53 through 99604. This means that, by establishing secure connections with newpartners, BIX members extend their local chain of verified certificates.In other words, the longer the local BCL, the more efficient theverification procedure for new certificates.

D. The BIX Certificates Ledger (BCL) Request/Response

During the procedure of verification of partners’ certificates, BIXmembers extend their local database of verified certificates. A longerBCL makes the verification procedure for certificates of new partnersmore efficient, as their certificates may be located between the currentmember's certificate and the last verified certificate in the user'slocal chain In that case, verification is simple, as the targetcertificate has already been verified, even though the BIX member neverhad a direct relationship with that particular partner.

This leads to the obvious conclusion that it is beneficial for a BIXmember to have all certificates currently in the BCL in his/her trusted(verified) local certificates chain, particularly all certificatesbetween the last verified certificate in the member's local chain andthe current tail of the BCL. But, as previously described, the BIXmember who is at the tail of the BCL is the current issuer of the nextcertificate. It is clear from the description of the verificationprocedure of the new certificate that the issuer is certainly the memberof the BIX system who is in possession of all certificates currently inthe BCL. Therefore, that BIX member is in the position to distribute thefull BCL to other members. This step may be performed automaticallyafter completion of the registration procedure for new BIX members. But,to not overload the system, this distribution is performed upon requestsby other BIX members.

When a BIX member wants to receive all certificates currently in theBCL, that member will send his/her own certificate to the BIXSynchronization System. This message is a Certificate Ledger Request andwill be distributed to all current BIX members, just as the CertificateRequest message Similarly, this request is received out of thecommunications and applications context, so it will be disregarded byall users except the current issuer.

The issuer will collect all verified certificates from his/her localchain, starting with the certificate in the request message and up tohis/her own certificate, he/she will build a Certificate Ledger Responsemessage, and return it to the requesting BIX member. The requestingmember will perform verification of each new certificate, starting withhis/her own and moving forward to the tail of the BCL and will store allnew certificates in the local database of verified certificates.

This procedure overloads the issuer, at least for a period of time, butit makes validation of partners' certificates for all other BIX membersin the system much more efficient. This is an example of thecommunity-based procedure, where one protocol is not optimal for onemember in the system, but is optimal for the overall community.

Protection of Private Cryptographic Keys

BIX System is completely resistant to all attempts of penetrations andillegal use of the system by unauthorized users by stealing secret orsensitive parameters that belong to regular BIX users. The corecryptographic mechanism of the BIX system is public key cryptography. Inall algorithms of that type, the sensitive and therefore secret elementis private key. If the private key is stolen, the intruder canimpersonate the victim. Such illegal action would enable the intruder toperform various transactions that require personal authentication.

Many different suggestions and solutions for this problem exist in theprior art literature, but they all have the same approach: protection ofthe private key by different security mechanisms. The practice has shownthat all such mechanisms, even if based on use of smart cards, are notperfect and can be either bypassed or broken.

So, the obvious conclusion, in order to effectively eliminate thisthreat, is the solution where private key does not even exist in thesystem. The logic of this approach is simple: if a private key does notexist, it cannot be stolen. Following this conclusion, it is furtherobvious that, since private key does not exist in the system, it must begenerated when needed to create signatures or open digital envelops.However, the approach cannot be generation of new private key wheneverneeded, since the corresponding public key and its certificate havealready been distributed and in possession of many members of the BIXsystem. Therefore, the final conclusion about the approach used in theBIX system is that private key is generated when needed, but in such away that it cryptographically corresponds to the public key/certificatealready in the system. This can be accomplished by using deterministicprocedure for generation of a key pair, with the seed represented by thesecret parameter memorized by the user and not stored in the system.

For two the most popular asymmetric cryptographic algorithms, generationof a key pair is deterministic procedure. For the RSA cryptographicalgorithm, two prime numbers are generated first, then the modulus, thenprivate key (based on the convention that the value of the public keyexponent is fixed, equal to 3 or 17). The procedure for generating twoprime numbers is deterministic if it uses the seed. Using for that seeduser's login parameter (which has fixed value) will always generate thesame key pair. For the ECDSA the procedure is even simpler, as theprivate key is any random value selected in the specified interval. Thatrandom value can be easily generated deterministically, by using thefixed seed.

The conclusion about this innovative idea for protecting privatecryptographic keys is that when a user logs into the BCI Agent, he/shegives his/her login parameter. This parameter is used as the seed togenerate private key and that key is then used in a challenge/responseauthentication protocol and all other cryptographic operations.

If a user decides to change login PIN/password, new key pair must begenerated and new certificate will be issued. Since BCL is append-onlyledger, current user's certificate cannot be modified to indicate thatit is revoked. This means that, after getting new certificate, the userwill have multiple certificates in the BCL. This implies that the BIXCertificates Ledger (BCL) Request protocol must always return the lastof all user's certificates stored in the ledger.

We claim:
 1. A cryptographically signed object containing the set ofattributes, called a BIX certificate, whose purposes are to bind thepublic key of a public/private cryptographic keys pair to the identityof its owner and to provide the mechanism for verifying that bindingbased on use of peer-to-peer protocols and public ledger. An instance ofa BIX certificate contains values of attributes identifying the owner ofthe certificate, its issuer, public key belonging to the owner ,andcryptographic parameters for verification of the certificate.
 2. The setof attributes of the BIX certificate from claim 1, called Header, thatidentifies the certificate, containing attributes: the sequence numberof the BIX certificate, its version, and issuing date/time. The value ofthe sequence number attribute is the sequence number of the BIXcertificate in the BIX Certificates Ledger. This segment may alsocontain other attributes identifying the certificate or its type.
 3. Thecryptographically signed set of attributes of the BIX certificate fromclaim 1, called Subject, that identifies the owner of the certificate,containing attributes: the identification number of the certificateowner in the BIX system, the date and time when the certificate wasissued, the identifier of the cryptographic algorithm that was used tosign it, and the public key belonging to the owner of the certificate.All attributes of the Subject segment are signed with the private keythat corresponds to the public key included in that segment.
 4. Thecryptographically signed set of attributes of the BIX certificate fromclaim 1, called Issuer, that identifies the entity that issued thecertificate, containing the attributes: the identification number of theBIX system member who issued the BIX certificate, the date and time whenthe certificate was issued, the identifier of the cryptographicalgorithm that was used to sign it, and the public key of the issuer ofthe certificate. All attributes of the Issuer segment are digitallysigned with the private key that corresponds to the public key includedin that segment.
 5. The cryptographically signed set of attributes ofthe BIX certificate from claim 1, called Next Subject, that identify theentity whose certificate has been issued by the owner of thecertificate, containing attributes: the identification number of the BIXsystem member whose certificate was issued by the owner of the BIXcertificate, the date and time when the certificate of the next BIXmember was issued, the identifier of the cryptographic algorithm thatwas used to sign the Next Subject segment, and the public key of theowner of the next certificate in the BIX Certificates Ledger. Allattributes of the Next Subject segment are digitally signed with theprivate key that corresponds to the public key included in the NextSubject segment.
 6. Two cross signature attributes of the BIXcertificate from claim 1: 1) the Backward Cross Signature, containsdigital signatures over concatenated hashes of the Header, Subject, andIssuer segments, created by the issuer and the owner of the BIXcertificate, and 2) the Forward Cross Signature, contains signaturesover concatenated hashes of the Header, Subject, and Next Subjectsegments, created by the owner of the BIX certificate and the owner ofthe next BIX certificate in the certificates ledger.
 7. The Extensionssegment of the BIX certificate from claim 1, which is extendiblecollection of attributes, each designating some special aspect, type, orpurpose of the BIX certificate.
 8. The private key object thatcorresponds to the public key included in the BIX certificate from claim1, which does not exist in the system, but it is generated when needed,by a deterministic procedure using fixed seed value, representing userlogin or any other parameter supplied by the user.
 9. BIX CertificatesLedger, a linear, double-linked list of BIX certificates withoutbranches. The ledger is global, distributed, synchronized, append-onlypublic storage of certificates.
 10. The special BIX certificate includedin the BIX Certificates Ledger of claim 9, called the Root Certificate,whose Subject segment is the same as its Issuer segment, i.e., thecertificate is self-signed. The Backward Cross Signature attribute ofthis certificate is not populated. The Root Certificate represents thehead of the BIX Certificates Ledger.
 11. The BIX certificates includedin the BIX Certificates Ledger of claim 9 belonging to BIX members whohave already issued certificates to their next BIX member. Thesecertificates have all their segments and attributes populated and theyare located in the middle section of the BIX Certificates Ledger,between the Root Certificate and the “tail” BIX certificate.
 12. The BIXcertificate included in the BIX Certificates Ledger of claim 9 belongingto the BIX member who last joined the BIX system and has not yet issueda certificate to the next BIX member. The Next Subject segment of thiscertificate is not populated. This certificate is located at the end ofthe BIX Certificates Ledger, representing the “tail” BIX certificate.13. The BIX Certificates Infrastructure, which is collection of softwarecomponents and protocols, each with a special function and specialpurpose that, when combined, perform the BIX certification protocols.14. The BIX Certificates Ledger, which is the component of the BIXCertificates Infrastructure of claim 13 that stores and distributes theobjects of the BIX Certificates Infrastructure, that is, BIXcertificates in the form of a double-linked list.
 15. The BIX IdentitiesSystem, which is the component of the BIX Certificates Infrastructure ofclaim 13 that registers entities, validates, protects, and distributesidentities of BIX members and provides cryptographic mechanisms fortheir verification by other members of the BIX system.
 16. The BIXSynchronization System, which is the component of the BIX CertificatesInfrastructure of claim 13 which performs (a) global synchronization ofrandom numbers used as personal identification numbers for their globaluniqueness within the entire BIX Certificates Infrastructure, (b)synchronization of the global Coordinated Universal Time (UTC), and (c)synchronization of newly issued certificates providing globallysynchronized unique state of the entire BIX Certificates Ledger.
 17. TheBIX Certificates Infrastructure Agent, which is the component of the BIXCertificates Infrastructure of claim 13 used by BIX members, implementedas a PC, Web, smart card, smart chip or mobile phone application to usethe services of the BIX Certificates Infrastructure.
 18. The BIXCertificates Protocols, which are used by BIX members to manage BIXcertificates using the BIX Certificates Ledger.
 19. The CertificationRequest/Response protocol of claim 18, which is used by new BIX memberswho want to join the BIX system by sending their Certification Requeststo the certificate-issuing BIX member and receiving their BIXcertificates.
 20. The Certificate Verification protocol of claim 18,used by new BIX members upon receiving their newly issued certificatesto verify the correctness of their new certificates.
 21. The CertificateRequest/Response protocol of claim 18, which is used by members of theBIX system to request and receive the BIX certificate of theirtransaction partners directly from the transaction partners.
 22. TheCertificate Ledger Request/Response protocol of claim 18, which is usedby members of the BIX system to request and receive the BIX certificateof their transaction partners from the BIX Certificates Ledger. BIXCertificates Ledger is indexed database, so the read is direct fetchoperation without search.